Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@app/components/AccountItem.vue`:
- Around line 202-206: getStepState currently treats a step as 'active' when
currentVerificationStep === stepIndex AND (isReverifying OR reverifyError),
which keeps the spinner running after a failure; update the condition in
getStepState (and the duplicate logic around the other block) to require
isReverifying to be true and reverifyError to be false (e.g., use
isReverifying.value && !reverifyError.value alongside the
currentVerificationStep/stepIndex check) so the step becomes non-active when a
reverifyError is set.
- Around line 165-175: The responsePromise created from $fetch (typed
KeytraceReverifyResponse) may reject while the subsequent runStep() delay calls
execute, causing unhandled rejection warnings; attach a rejection handler
immediately by calling Promise.allSettled([responsePromise]) (or otherwise
attach .catch) before invoking runStep(0..3), then await the original
responsePromise later as before so your existing try/catch still handles the
outcome; update the code around responsePromise and the runStep sequence in
AccountItem.vue accordingly.

In `@app/components/Compare/FacetSelector.vue`:
- Around line 108-113: The hover styles conflict between the static class
attribute and the conditional :class for facet.comingSoon, causing enabled hover
utilities (hover:(text-fg-muted border-border)) to potentially override the
muted hover (hover:(text-fg-subtle/50 border-border-subtle)); fix by moving
hover:(text-fg-muted border-border) out of the base class and into the
non-coming-soon branch of the :class binding (so only the enabled branch adds
enabled hover utilities), or alternatively replace with a disabled: modifier
pattern consistent with Button/Base.vue and Select/Base.vue so coming-soon chips
only receive the muted hover styles via facet.comingSoon conditional logic.

In `@app/components/LinkedAccounts.vue`:
- Around line 22-49: Replace hardcoded UI strings in the LinkedAccounts.vue
template with i18n lookups: use $t('profile.linked_accounts.title') for "Linked
Accounts"; replace the verified summary line that uses
verifiedCount/accounts.length with a translated key like
$t('profile.linked_accounts.verified_summary', { verified: verifiedCount, total:
accounts.length }); map each entry in statusLegend to use
$t('profile.linked_accounts.status.<key>') for the four legend labels and use
$t('profile.linked_accounts.legend_label') for the container aria-label; replace
"No linked accounts" with $t('profile.linked_accounts.empty'); ensure you update
the template expressions around verifiedCount, accounts, statusLegend, loading,
SkeletonBlock and AccountItem to call $t(...) consistently with the new
profile.* keys added to i18n/locales/*.json.

In `@app/components/ProfileHeader.vue`:
- Around line 53-67: Replace the hardcoded English strings in ProfileHeader.vue
with i18n lookups: change the alt fallback "Profile avatar" and the name
fallback "Unknown Profile" to use this.$t (or $t) with dedicated keys (e.g.
profile.avatarAlt and profile.unknown) so they respect the active locale; update
any template references that use profile.name || 'Unknown Profile' and
:alt="profile.name || 'Profile avatar'" to use the translated fallbacks, and add
corresponding keys under the profile.* namespace in the translation files to
match the project's i18n pattern.

In `@app/pages/profile/`[identity]/index.vue:
- Around line 101-105: The Keytrace UI (ProfileHeader and LinkedAccounts) is
being rendered for all identity routes because useKeytraceProfile(identity) is
invoked unconditionally and the mock API returns synthesized profiles for
unknown domains; update the rendering to gate the Keytrace-related components by
detecting domain-like identities (e.g. a simple regex check on identity) or by
checking a real Keytrace signal before rendering: call
useKeytraceProfile(identity) only when identity matches a domain pattern (or add
a boolean like isDomainFromIdentity) and wrap ProfileHeader and LinkedAccounts
with that condition (references: useKeytraceProfile, ProfileHeader,
LinkedAccounts, identity) so non-domain handles do not show fabricated linked
accounts.

In `@i18n/locales/de-AT.json`:
- Around line 27-28: The strings for keys "likes_error" and "likes_empty"
currently say "Beliebte Pakete" (popular packages) but should refer to the
user's liked packages; update the translations for likes_error and likes_empty
so they use a German phrase meaning "liked packages" (e.g., use a localized term
such as "Gemerkte Pakete" or "Gelikte Pakete") to correctly reflect the
profile's liked-packages section.

In `@i18n/locales/te-IN.json`:
- Around line 126-128: The three Telugu locale entries
"public_interests_description", "likes_error", and "likes_empty" are still in
English; update their values to proper Telugu translations (replace the English
strings with Telugu equivalents) or remove these keys from te-IN.json until
translations are available so Telugu users don't see English UI; locate these
keys in the i18n/locales/te-IN.json file and either provide accurate Telugu text
for public_interests_description, likes_error, and likes_empty or revert/delete
them to keep the locale as a placeholder.

In `@server/api/keytrace/reverify.post.ts`:
- Around line 21-26: The current reverify handler always returns a
KeytraceReverifyResponse with status: 'unverified', which will incorrectly
downgrade verified accounts; update the handler that builds the response (the
code creating the response object in reverify.post) to preserve the account's
current status instead of hardcoding 'unverified' — e.g., read the incoming
request's currentStatus (or fetch the account's status from the same source the
UI uses) and set response.status = currentStatus, adjust failureReason to
null/empty when status is unchanged, and only set failureReason and 'unverified'
if a real verification attempt fails.

In `@test/e2e/interactions.spec.ts`:
- Around line 293-310: The test '"s" does not navigate when any modifier key is
pressed' is ambiguous because it focuses '#header-search' causing typed
modifiers like 'Shift+s' to insert text and potentially trigger navigation;
remove the focus and the subsequent expect(searchInput).toBeFocused() lines from
this test so it mirrors the '"c"' modifier test (no editable focused) and
reliably asserts the URL stays on /settings; if you need coverage for shortcuts
being suppressed while an editable is focused, add a separate test named e.g.
'"s" is suppressed while editable is focused' that focuses '#header-search' and
verifies an unmodified 's' does not trigger navigation.

---

Nitpick comments:
In @.github/workflows/ci.yml:
- Around line 117-118: Replace the hard-coded path in the "👑 Fix Git ownership"
step by using the GitHub Actions runtime variable: update the git config
--global --add safe.directory command to use $GITHUB_WORKSPACE instead of the
literal "/__w/npmx.dev/npmx.dev" so the safe.directory is set dynamically for
the checked-out repo.

In `@app/components/LinkedAccounts.vue`:
- Around line 4-9: The statusLegend array uses raw Tailwind color utilities
(statusLegend, className) which bypass the app's semantic design tokens; replace
these hardcoded palette classes with semantic token-based classes (e.g., create
status-specific utility classes like .status-verified, .status-unverified,
.status-stale, .status-failed that map to tokens such as bg-bg-subtle /
text-fg-muted / border-border or token variants for each status) and update
statusLegend.className to reference those semantic classes so the badges respect
theme/accent settings and verify contrast in both light and dark themes.

In `@app/composables/useKeytraceProfile.ts`:
- Line 1: The explicit import of KeytraceAccount and KeytraceResponse at the top
of useKeytraceProfile.ts duplicates the repo's Nuxt auto-imports for
shared/types in composables; remove the line "import type { KeytraceAccount,
KeytraceResponse } from '#shared/types/keytrace'" and rely on the project-wide
auto-imported types (references to KeytraceAccount and KeytraceResponse inside
the useKeytraceProfile composable should continue to work without the explicit
import).

In `@CONTRIBUTING.md`:
- Line 351: Update the CONTRIBUTING.md note to mention that Nuxt's typedPages
option is experimental and that the type-safety guarantees for using
object-syntax named routes depend on enabling typedPages in nuxt.config.ts;
specifically, add a short parenthetical after the sentence that recommends
"object syntax with named routes" referencing the experimental nature of the
typedPages option and instructing contributors to enable typedPages in
nuxt.config.ts to get the typed route benefits.

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@i18n/locales/de-DE.json`:
- Around line 16-17: The German locale entry "verified_summary" currently is a
static label and must include the interpolation placeholders used by
app/components/LinkedAccounts.vue; update the "verified_summary" value in
i18n/locales/de-DE.json to include the {verified} and {total} placeholders (e.g.
a German phrase using {verified} and {total}) so the component's passed values
are rendered in the UI.

In `@i18n/locales/en.json`:
- Around line 378-379: The "verified_summary" translation currently returns a
static label; update the en.json "verified_summary" value to include
interpolation placeholders for the counts (e.g., {verified} and {total}) so the
string uses the { verified, total } values passed from
app/components/LinkedAccounts.vue; keep the placeholder names matching what
LinkedAccounts.vue supplies and preserve pluralization/formatting conventions
used by your i18n setup.

In `@i18n/schema.json`:
- Around line 1114-1130: The AccountItem.vue component is still using hardcoded
English labels for account status; update it to read the new i18n keys under
profile.linked_accounts.status (e.g. profile.linked_accounts.status.verified,
.unverified, .stale, .failed) instead of literal strings. Locate the status
display logic in AccountItem.vue (the template or computed that currently
returns "Verified", "Unverified", "Stale", "Failed") and replace those literals
with calls to the translation helper (e.g. this.$t or $t in the template) so the
UI uses profile.linked_accounts.status.* keys for all four statuses. Ensure any
mapping logic (status code -> label) uses the translation keys consistently and
falls back to a safe default if a key is missing.

---

Outside diff comments:
In `@i18n/locales/de.json`:
- Around line 300-344: Restore the removed "common.error" key in the German
locale so existing consumers (e.g., the lunaria-status mock that references
common.error) continue to find a translation; add an appropriate German string
like "Fehler" or a full sentence under the "common" object with the key "error"
to mirror other locales, ensuring the key name is exactly "common.error" so code
paths referencing common.error (such as the handler in
app/storybook/mocks/handlers/lunaria-status.ts) work without changes.

In `@i18n/locales/en.json`:
- Around line 305-349: Restore the removed translation key by re-adding "error"
under the "common" object in the locale (so common.error exists) with an
appropriate string (e.g., "Error") because
app/storybook/mocks/handlers/lunaria-status.ts still references common.error;
alternatively update that handler to use an existing key if you intend to remove
common.error, but do one of these so the missing translation key is resolved.

In `@i18n/locales/ja-JP.json`:
- Around line 171-210: The ja-JP locale removed the common.error key which
breaks consumers expecting it (storybook mock in
app/storybook/mocks/handlers/lunaria-status.ts references common.error); restore
the common.error string in the "common" object of i18n/locales/ja-JP.json with
an appropriate Japanese translation (e.g., "エラーが発生しました") so the mock translation
payload and any runtime lookups find the key.

---

Nitpick comments:
In `@i18n/locales/de-AT.json`:
- Around line 24-43: The de-AT locale duplicates the entire "profile" block from
the base German locale; remove the redundant keys under "profile" in de-AT.json
and leave only Austria-specific overrides (if none, remove the "profile" object
entirely) so the app falls back to de.json for shared strings; target the
"profile" object and its nested keys like "public_interests_description",
"likes_error", "likes_empty", "avatar_alt", "unknown_profile", and the
"linked_accounts" block when pruning duplicates.

In `@test/nuxt/a11y.spec.ts`:
- Around line 910-968: Add a few more a11y test cases to exercise non-happy-path
states: for ProfileHeader add tests for loading: true and for a profile without
an avatar (initials fallback) using mountSuspended(ProfileHeader) and runAxe;
for LinkedAccounts add tests for accounts: [] (empty list), loading: true, and a
mixed list containing statuses 'unverified', 'stale', and 'failed'; for
AccountItem add separate tests rendering AccountItem for each non-verified
status ('unverified','stale','failed') and run runAxe against each mounted
component to assert no violations. Ensure each test uses the same
mountSuspended/props pattern so the axe audit covers fallback avatar, status
badges, and loading skeleton ARIA states.